
TDA Progress Report 42-59 


N80-33434 

July and August 1 980 


DSN Ground Communications Facility 

R. H. Evans 
TDA Engineering Section 


A functional description of the GCF and its relationships with other elements of the 
DSN and NASCOM is presented together with development objectives and goals and 
comments on implementation activities in support of flight projects. 


I. Introduction 

The Ground Communications Facility (GCF) is one of the 
three elements of the DSN. The GCF provides for transmis- 
sion, reception, and monitoring of Earth-based point-to-point 
communications between the Deep Space Stations (DSSs, one 
of the DSN elements), the Network Operations Control Center 
(NOCC, the other element) located at JPL, Pasadena, and the 
Mission Operations Control Center (MOC) at JPL. Voice, 
teletype, high-speed data, and wideband data channels of the 
world-wide NASA Communications Network (NASCOM) are 
utilized for all long-distance circuits, except those between 
JPL and the Goldstone Deep Space Communications Complex 
(GDSCC). Goddard Space Flight Center (GSFC) NASCOM 
Engineering has delegated the responsibilities for planning, 
budgeting, design, implementation, operation, and mainte- 
nance of the communications requirements between Gold- 
stone and JPL to the DSN GCF. Additionally, the GCF 
provides communications services between the DSSs at each 
geographic communications complex (Spain, Australia and 
Goldstone, Cahf.) via intersite microwave system capabilities, 
and between separated areas of the NOCC at JPL via 
230-kbit/s wideband data channels. Also, voice communica- 
tions are provided within the stations, between the stations, 
•within the complexes, and within the NOCC. The GCF is 


comprised of eight subsystems; Voice, Teletype, High-Speed 
Data, Wideband Data, Monitor and Control, Data Records, 
Network Log Processor, and Network Communications Equip- 
ment. The DSN Tracking and Data Acquisition Engineering 
Office of JPL provides the technical direction and systems 
management of the GCF and acts as the representative of 
NASCOM for switching and interconnect functions on the 
West Coast. 


II. GCF-NASCOM Interrelationships 

The interrelationships at the programmatic level between 
JPL’s DSN GCF and the NASCOM network, managed, 
engineered, and controlled at GSFC, are characterized as 
follows; 

NASCOM: 

(1) Provides long-haul operational ground communica- 
tions in support of all NASA projects and mission 
activities including those supported by the DSN. 

(2) Accepts and supports communications requirements 
established by the DSN and validated through con- 
tinuing consultation and review. 
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(3) Establishes in consultation with the users the basic 
characteristics of the NASCOM systems, such as tele- 
type line rate and block header formats for switching, 
and the user electrical interfaces. 

GCF; 

(1) Provides ground communications for ah DSN missions 
and uses the services of NASCOM. 

(2) Estabhshes additional characteristics of ah GCF subsys- 
tems on an end-to-end basis such as block multiplexing, 
error correction, monitoring and control, and data 
records capabhities. 

III. Objectives and Goals 

The primary objectives of the GCF are to provide highest 
quahty point-to-point transfer of operational data within the 
DSN and provide simple user and NASCOM electrical and 
operational interfaces. These objectives are being met by; 

(1) Providing automatic message switching and routing. 

(2) Providing data transmission subsystems that are as 
transparent to the user as possible. 

(3) Minimizing project-dependent equipment within the 
GCF. 

(4) Providing a centralized common user data records 
capabihty. 

The goals of the GCF are to provide highly reliable and 
cost-effective data transmission whhe continuing an adequate 
capability balance for multiple mission users. These goals 
include the foUowing: 

(1) Equipment and routing redundancy to minimize single- 
point-of-failure impact. 

(2) Error performance which provides essentiahy block- 
error-free throughput. 

(3) Design coordinated and consistent with the NASCOM 
Development Program. 


IV. Configuration and Functionai 
Subsystem 

The current GCF configuration, including the related 
NASCOM interfaces and functions, is illustrated in Fig. 1. This 
configuration illustrates the long-haul communication circuit 
services external to JPL and Deep Space Communications 
Complexes (except circuits between the Goldstone Complex 
and JPL) which are the responsibility of NASCOM. The Voice, 
Teletype, High-Speed Data, Wideband Data, and Monitor and 


Control Subsystems point-to-point communications are ser- 
viced by this Fig. 1 configuration. 

A. High-Speed Data Subsystem 

This subsystem shall consist of GCF assemblies that switch, 
transmit, record, process, distribute, test, and monitor digital 
data and is used for transmission of: 

(1) All digital data for the DSN Command, Tracking, and 
Monitor Control Systems. 

(2) All low or medium rate data of the DSN Telemetry, 
Radio Science, Very Long Baseline Interferometry 
(VLBI), and the DSN Test and Training System. 

The High-Speed Data Subsystem provides a capability for 
transmitting and receiving the serial bit stream formatted data 
over a properly conditioned full duplex alternate voice/data 
chaimel having a 3.0-kHz bandwidth. This serial bit stream is 
impressed on communication circuits at a continuous line bit 
rate divided into message segments referred to as high-speed 
data blocks. 

Two types of data blocks are used: 

(1) Data blocks containing user data bits to be transmitted. 

(2) Filler blocks containing filler data bits provided by the 
GCF when the user data bit/block rate is insufficient to 
maintain the contiguous bit/block rate required for 
continuous line monitoring and error control. 

Current capabilities for the GCF Mark III period provide 
the functional capabilities illustrated in Fig. 2. The GCF 
High-Speed Data Subsystem is standardized on a 1200-bit 
block size (message segment) and a line bit rate of 7200 bit/s. 
Subsystem changes to bring about the Mark III capabilities 
included conversion from a 33-bit to a 22-bit error detection 
encoding/decoding polynomial code and increasing the num- 
ber of bits reserved in the data block ending from 36 to 40 
bits. The 40-bit block ending with the 22-bit code facilitates 
numerical serialization and acknowledgement numbers for 
error correction by retransmission for short outages or errors 
in GCF end-to-end data transmission. 

The error correction capability has significantly reduced the 
post-pass time required for non-real-time replay of blocks 
received in error to complete the intermediate data record. 
Figure 3 illustrates the High-Speed Data Subsystem transi- 
tional configuration (in a simplified manner) that was plaimed 
for the CY 1977 and CY 1978 time period. The transitional 
configuration (old and new configurations and interfaces 
separately or in combinations operational and usable) was 
required to provide continuous support for ongoing and new 
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projects starting up until the conversion from the old Ground 
Data System to the new one was completed to support 
Voyager and Pioneer Venus Projects and the continued 
extended mission of the Viking Project through early CY 1979 
(subsequent Viking mission extensions caused continuance of 
old system and its interfaces until March 1980). The dual- 
mode configuration became operable and usable to support 
DSN System Testing in November 1977. The added new 
computer-to-computer switched interface became operational 
in limited form in early CY 1978 serving the Pioneer Venus 
Project, other ongoing Pioneer Projects, and the Helios Project 
with the new Ames Research Center and DSN-NOCC interface 
in the 22-bit polynomial error detection mode. This new 
computer switched interface to the Mission Control and 
Computing Center (MCCC) became operational supporting the 
Voyager Project in September 1978. The Voyager Project 
began using the high-speed data subsystem in the error 
correction mode on November 11, 1978, with the Helios and 
Pioneer Project following suit shortly thereafter. 

The Viking Project agreed to convert to the new standard 
22-bit error detection code, for the final mission extension 
beginning in March 1980. The high-speed data subsystem CCT 
equipment was then reconfigured to eliminate the transitional 
configuration and the old 33-bit error detection encoding/ 
decoding equipment and hardware interfaces to the NOCC and 
MCCC. 


B. Wideband Data Subsystem 

The Wideband Data Subsystem consists of assemblies that 
switch, transmit, receive, process, distribute, test and monitor 
data requiring the use of bandwidths greater than those 
provided by standard high-speed data channels. The GCF 
Wideband Data Subsystem functionally illustrated in Fig. 4, 
together with a listing of functional capabilities provided, 
includes standard wideband circuits as well as all intersite 
microwave (area microwave) capabilities. The Wideband Data 
Subsystem is used for the transmission of: 

(1) All DSN Telemetry System high-rate data that exceed 
High-Speed Data Subsystem capabilities. 

(2) Data interchange between the NOCC and GCF Com- 
munications Terminal at JPL. 

(3) Data interchange between DSSs within a complex via 
intersite microwave, including critical timing signals 
and receiver baseband signals for anterma arraying and 
signal combining systems support. 

(4) Simulation System Data from the Mission Control and 
Computing Center/Mission Operations Center to the 
DSSs. 


(5) DSN Test and Training System data from the Network 
Operations Control Center to the DSSs. 

The wideband data circuits for interchange of data between 
the DSSs and JPL are impressed with serial bit streams at a 
continuous line rate, typically 56,168, or 230.4 kbit/s, divided 
into 2400- or 4800-bit message segments (data blocks). The 
2400-bit block size will no longer be used since the last user 
Viking Mission orbiting spacecraft operation was terminated in 
July 1980. Similar to the high-speed data subsystem, the 
blocks are either data blocks or filler blocks inserted when the 
user data load is insufficient to maintain contiguous data 
blocks. 

Engineering planning and design effort was to begin in 
FY 1979 to implement error correction capabihty into the 
wideband data subsystem for inbound data from the DSSs to 
JPL. This task was delayed and will now be considered for 
inclusion in the Block IVA GCF design. 

C. Voice Subsystem 

The Voice Subsystem consists of GCF assemblies that 
switch, transmit, receive, distribute, test, and monitor trans- 
missions originally generated in vocal form, and includes 
internal voice communications within the Deep Space Station 
Communications Complexes, DSSs, and the NOCC. The 
subsystem service provides capabilities between those areas 
and to non-DSN area interfaces as follows: 

(1) NOCC and DSS. 

(2) NOCC and MCCC/MOC (or remote MOC). 

(3) MOC and DSS for Command System backup. 

The Voice Subsystem functional capabilities and key 
characteristics include: 


(1) Standard voice-data grade circuits for all traffic. 

(2) Conferencing capability on one intercontinental circuit 
during noncritical periods for all deep space stations 
supporting a single project (individual circuits for each 
DSS during critical periods, resources permitting). 

(3) User-controlled intercom switching. 

(4) Circuits used for high-speed data transmission (backup) 
if required. 

(5) Voice traffic recording in the central communications 
terminal upon request. 
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D. Teletype Subsystem 

The teletype (TTY) subsystem was converted from 5-level 
Baudot format to eight-level ASCII (American Standard Code 
for Information Interchange) national standard. GCF and 
NASCOM engineering began the work in 1979 and completed 
the conversion of all GCF equipment terminals in August 
1980. 

The subsystem consists of assembUes that switch, transmit, 
receive, distribute, test and monitor digital signals at a TTY 
line rate of 100 words per minute. The operational use of 
teletype continues to be de-emphasized and is used primarily 
for emergency backup operational transmissions and adminis- 
trative communications. Service functions and key character- 
istics include: 

(1) Handling Air Force Eastern Test Range (AFETR) 
generated predicts for DSN initial acquisition. 

(2) Transmitting nonoperational messages between the JPL 
Message Center and other locations. 

(3) Use of standard NASCOM format and the NASCOM 
communications processor for message switching. 

(4) Employment of time division multiplexing techniques 
to reduce trunk circuit costs. 

E. Monitor and Control Subsystem 

The Monitor and Control Subsystem consists of assemblies 
that collect, process, and display the status and performance 
of the GCF Subsytems in real-time. The Monitor and Control 
Subsystem with a Usting of functional capabilities illustrated in 
Fig. 5 includes minor subassemblies located at each DSS in the 
CMF to interface station GCF function status and perfor- 
mance indicators to the CMF for monitor block formatting 
and transfer to the Central Communications Monitor (CCM) 
Processor at JPL. The CCM also receives real-time status and 
performance information from local GCF subsystems. All 
real-time status and performance information received by the 
CCM is processed and displayed relative to preset standards 
and limits to facilitate operations monitoring and technical 
control. Information and alarms are displayed on continuous 
line performance and data flow throughput error control. 

F. Data Records Subsystem 

The DSN requirements for the data record processing and 
production functions are implemented in the GCF Data 
Records Subsystem. The Data Records Subsystem consists of 
assembUes in the CCT that log in real-time, monitor, identify 
gaps, provide for processing and editing of data gap lists, 
control data gap recalls from the DSSs and the generation and 
accounting for Intermediate Data Records (IDRs) and fiU data 
records selected from records of the GCF real-time log. 


The existing Data Records capabiUty is a coUection of 
functions distributed through the Data Records Processor, the 
GCF Network Log and the Network Communications Equip- 
ment Subsystems, which uses the NOCC Real-Time Monitor 
and Network Support Processors to identify, process and edit 
the gap Usts. 

G. Network Log Processor Subsystem 

The Network Log Processor (NLP) Subsystem consists of 
GCF miniprocessors, multiple mag tape units, and peripheral 
I/O assemblies that switch, transmit, receive, process, and 
record data. The NLP subsystem assemblies are located in the 
Central Communications Terminal (CCT) for interfacing the 
CCT with the remotely located DSN Network Data Processing 
Area (NDPA) and the NDPA with the Network Operations 
Control Area (NOCA) (see Fig. 6). 

The NLP Subsystem provides a Deep Space Network 
Operations Control interface to monitor and log aU data 
transferred between the DSSs and the local and remote MOCs, 
to receive aU inbound DSS Monitor and Control Response 
Data, and to transmit all predicts and control messages from 
the NOCA to the DSSs. 

H. Network Communications Equipment Subsystem 

The Network Communications Equipment (NCE) Subsys- 
tem consists of GCF miniprocessors and peripheral I/O 
assemblies that switch, transmit and receive data. The NCE 
Subsystem assembUes are located in the remote NDPA 
(roughly three quarters of a cable mUe distant from the CCT in 
Building 202 at JPL). The NCE assembUes comprise a GCF 
Area Communications Terminal located adjacent to the 
NDPA. 

The NCE interchanges multiplexed block formatted data 
with the NLP subsystem processors located in the CCT over 
three fuU-duplex 230-kbit/s wideband data channels extending 
the GCF interface to the NDPA (see Fig. 6). This GCF-NDPA 
interface function provides for 

(1) Processing data for transmission to and accepting data 
from the GCF CCT. 

(2) Multiplexing/demultiplexing and buffering data for aU 
NDPA processors. 

(3) Routing data to and from NDPA processors. 

V. Typical Configuration 

The DSN GCF is designed for multiple mission support. 
Improvements and additions are integrated to meet new era 
and project requirements (Voyager and Pioneer-Venus require- 
ments were completed in CY 1978) while continuing to 
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support the Viking, Helios, and Pioneer 6 through 1 1 Projects. 
Plans for West Coast Switching Center support of the IRAS 
Project are completed. Requirements for the ISPM and Galileo 
projects are being defined and included in ongoing plans. 
Figure 7 illustrates, in general, the GCF configuration for 
support of these projects. Additionally, remote information 
centers and other non-DSN NASCOM-serviced installations on 
the West Coast are serviced through the NASCOM West Coast 
Switching Center,, an integral part of the GCF 20/Central 
Communications Terminal at JPL. 

VI. Implementation Activities 

A. GCF-NOCC Reconfiguration^ 

The task to reconfigure the CCT was begun with require- 
ments specifications established in March 1979 and a respon- 
sive design review in October 1979. In brief, the reconfigured 
CCT will: 

(1) Reduce the number of computers in use. 

(2) Provide a more timely IDR production capability. 

(3) Reduce the complexity of the man/machine interface. 

(4) Reduce manpower required at the CCT. 


iSee Refs. 1 and 2. 


(5) Release the wideband data subsystem Coded Multi- 
plexer/Demultiplexers for reinstallation at the 34-meter 
DSSs. 

(6) Increase the capacity to handle simultaneous wideband 
data fines at the CCT. 

(7) Provide a central console at the CCT fo’’ control and 
monitoring of all GCF subsystems. 

B. Mark IVA GCF 

Implementation planning and design to meet the require- 
ments of the DSN’s Mark IV Long Range Plans was begun in 
late 1979. The priority design and implementation effort will 
be to consolidate the data communications interfaces to a 
single communications processor interface at each of the three 
Deep Space Communications Complexes (DSCC). This single 
interface processor will accommodate the DSN’s Networks 
Consolidation Program plans for a single signal processing 
center located at each DSCC. Other less significant GCF 
changes and additions required within the DSCC’s along with 
minor changes at the CCT are included in this effort, which is 
to be completed in 1985 via a transitional phased implementa- 
tion. With the consolidation of the networks the GCF will see 
a significant increase in data communications requirements, as 
both deep space and high elliptical near-earth orbiting space- 
craft tracking and data acquisition data throughput will pass 
through the single communications processor interface with 
the DSCC. 
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